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Choosing a "Common IGP" for the IP Internet 
(The IESG’s Recommendation to the IAB) 


Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 


Special Note 


This document was originally prepared as an Internet Engineering 
Steering Group (IESG) recommendation to the Internet Architecture 
Board (IAB) in mid-summer 1991, reaching the current version by the 
date shown above. Although the document is now somewhat dated (e.g., 
CIDR and RIP II are not mentioned), the IESG felt it was important to 
publish this along with the recent OSPF Applicability Statement [11] 
to help establish context and motivation. 


Abstract 


This memo presents motivation, rationale and other surrounding 
background information leading to the IESG’s recommendation to the 
IAB for a single "common IGP" for the IP portions of the Internet. 


In this memo, the term "common IGP" is defined, the need for a common 
IGP is explained, the relation of this issue to other ongoing 
Internet Engineering Task Force (IETF) routing protocol development 
is provided, and the relation of this issue to the goal for multi- 
protocol integration in the Internet is explored. 


Finally, a specific IGP is recommended as the "common IGP" for IP 
portions of the Internet -- the Open Shortest Path First (OSPF) 
routing protocol. 


The goal of this recommendation is for all vendors of Internet IP 


routers to make OSPF available as one of the IGP’s provided with 
their routers. 
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1. Background 


There is a pressing need for a high functionality non-proprietary 
"common" Interior Gateway Protocol (IGP) for the TCP/IP protocol 
family. An IGP is the routing protocol used within a single 
administrative domain (commonly referred to as an "Autonomous System" 
(AS). 


By "common", we simply mean a protocol that is ubiquitously available 
from all router vendors (as in "in common"). Users and network 
operators have expressed a strong need for routers from different 
vendors to have the capablity to interoperate within an AS through 
use of a common IGP. 


Note: Routing between AS’s is handled by a different type of routing 


protocol, called an "Exterior Gateway Protocol" ("an EGP", of which 
the Border Gateway Protocol [2] and "The Exterior Gateway Protocol" 
[3] are examples.) The issues of routing between AS’s using "an" EGP 


is not considered in this memo. 


There are two IGPs in the Internet standards track capable of routing 
IP traffic -- Open Shortest Path First (OSPF) [4] and Integrated IS- 
IS [5] (based on the OSI IS-IS). These two protocols are both modern 
"link state" routing protocols, based on the Dijkstra algorithm. 
There has been substantial interaction and cooperation among the 
engineers involved in each effort, and the protocols share some 
similar features. 


However, there are a number of technical design differences. Most 
noteably, OSPF has been designed solely for support of the Internet 
Protocol (IP), while Integrated IS-IS has been designed to support 
both IP and the OSI Connectionless Network Layer Protocol (CLNP) 
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simultaneously. 
2. Multiple Internet Standard Routing Protocols Possible 


The Internet architecture makes a distinction between "Interior 
Gateway Protocols (IGPs)" and "Exterior Gateway Protocols (EGPs)". 
IGPs are routing protocols used within an Autonomous System (AS), and 
EGPs are routing protocols used between different AS’s. 


Therefore, the Internet architecture supports the use and 
standardization of multiple IGP routing protocols. For example, it 
is perfectly reasonable for one standard routing protocol to be used 
within one AS; while a second standard routing protocol is used 
within a second AS; at the same time that a non-standard proprietary 
routing protocol is used within a third AS. 


The primary purpose for making standards is to allow 
interoperability. Setting a protocol standard in the Internet says, 
in effect, "if you wish to use this protocol, you should do it as 
specified in the standard so that you can interoperate with others 
who also wish to use this protocol." It is important to understand 
that simply specifying a standard does not, by itself, designate a 
requirement to use the standard. It is merely meant to allow 
interoperability among those who choose to follow the standard. 


Therefore, it is reasonable for both OSPF and Integrated IS-IS to be 
progressed through the Internet Standards process as appropriate 


(based on the criteria specified in [6]). In addition, it is 
possible that other IGPs may be developed and standardized in the 
future. 


3. A Common IGP 


Although the Internet architecture allows for multiple standard IGP 
routing protocols, interoperability of router products from different 
vendors within a single AS would be greatly facilitated if a single 
"common" IGP were available from all router vendors. Designating a 
single common IGP would have the goal of enabling multi-vendor router 
interoperation with a modern high functionality routing protocol. 


However, designating a common IGP does not mandate the use of that 
IGP, nor would it be meant to discourage the use of other IGPs in 
situations where there may be sound technical reasons to do so. 


4. Impact of Multi-protocol Topology and Integrated IP/CLNP Routing 


There are topology considerations which will affect the designation 
of a "common" Internet IGP. 
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The Internet requires support for a wide variety of protocol suites. 
If we consider only IP and OSI CLNP, then the Internet is expected to 
contain: 


1. Pure IP AS’s (in which IP is used but OSI CLNP is not used); 
2. Pure CLNP AS’s (in which CLNP is used but IP is not used); 


3. Dual IP/CLNP ASs, with a common topology (i.e., all links and 
routers in the AS support IP and CLNP, and a single common 
topology is used for both protocol suites); 


4. Dual, overlapping IP/CLNP ASs with differing topologies (i.e., 
some links are dual, while some are IP-only and some are 
CLNP-only, resulting in different topologies for IP routing and 
CLNP routing). 


For (1), (i.e., a pure IP environment) any IGP capable of routing IP 
traffic could be used (e.g., OSPF or Integrated IS-IS). 


For (2), (i.e., a pure CLNP environment) any IGP capable of routing 
CLNP traffic could be used (e.g., OSI IS-IS or Integrated IS-IS). 


For (3), (i.e., routing environments in which both IP and CLNP are 
present in a common topology) there are two possibilities for managing 
routing: 


1. Separate routing protocols could be used for each supported 
protocol suite. For example, OSPF may be used for calculating 
routes for IP traffic and OSI IS-IS may be used for calculating 
routes for OSI traffic. Or Integrated IS-IS could be used for 
calculating routes for IP traffic and OSI IS-IS could be used 
for calculating routes for CLNP traffic. 


This approach of using separate routing protocols and management 
for each supported protocol family has come to be known as "Ships 
in the Night" because the two routing protocols share the 
hardware/software resources of the router without ever actually 
interacting on a protocol level. 


2. "Integrated routing" could be used, in which a single routing 
protocol is used for both IP and CLNP. At this time, Integrated 
IS-IS is the only choice for "integrated routing". 


For (4), (i.e., routing environments in which both IP and CLNP are 
present but in an overlapping different topology) separate routing 
protocols are required for the IP and CLNP environments (i.e., "Ships 
in the Night"). This is equivalent to two separates cases of (1) and 
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(2), but it is pointed out here as a separate case for completeness. 
5. Commitment to both IP and CLNP 


The IAB/IETF are committed to a timely introduction of OSI into the 
Internet. In recognition of this commitment, the IETF has an entire 
area devoted to OSI integration. 


However, while this introduction is taking place, it is essential 
that existing services based on IP be continued. Furthermore, IESG 
also feels that even after more widespread introduction of CLNP, IP 
and CLNP will continue to coexist in the Internet for quite some 
time. This view is consistent with the IAB goal of a multi-protocol 
Internet. 


Therefore, the IESG has a strong commitment to the continued support 
for IP throughout the Internet. Maintenance of this IP support 
requires selection of a common IGP suitable for support of IP, and 
requires that this selection be based on operational experience. 


6. Some History 


In February 1990, the IESG recommended that the question of 
designating a "common" IGP be postponed until more information was 
available from each protocol. More than a year has now passed since 
the IESG’s recommendation. There have been significant advancements 
in specification, implementation, and operational experience with 
each protocol. It is now reasonable to re-open the consideration of 
designating a "common IGP". 


At the March 1991 meeting of the IETF, the IETF Routing Area Director 
presented a set of criteria for the advancement of routing protocols 
through the Internet standards process [6]. More information 
regarding the IAB Internet Standards process can be found in [1]. 


Also, at the March 1991 meeting of the IETF, the OSPF Working Group 
requested that OSPF be considered for advancement to Draft Internet 
Standard. The OSPF WG submitted four documents to the IETF to 
support its request: 

o a revised protocol specification to update [4]; 

o an SNMP Management Information Base (MIB); 

o two technical reports giving a technical analysis and operational 


experience with OSPF. These reports follow the format recommended 
in [6]. 
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These four documents have now been published as [7, 8, 9, 10] 
respectively. 


In summary for OSPF: 


o all features of OSPF have tested (although not all features have 
been used in operation), 


o OSPF has been shown to operate well in several operational 
networks containing between 10 and 30 routers, 


o interoperation among routers from multiple vendors has been 
demonstrated at organized "bakeoffs". 


In May 1991, the IAB approved the IETF/IESG recommendation to advance 
OSPF to Draft Internet Standard. 


Integrated IS-IS, as specified in [5], is currently a Proposed 
Internet Standard. In July 1991, the status of Integrated IS-IS is 
as follows: 


o There are several separate implementations of integrated 
IS-IS under development, 


o Integrated IS-IS has worked well in several multi-area operational 
networks, one containing between 20 and 30 routers, 


o These recent operational results have not yet been fully 
documented. Documentation, showing satisfaction of the criteria 
given in [6] for advancing routing protocols, will be submitted 
to the IESG when Integrated IS-IS is submitted for Draft Internet 
Standard status. 


7. IESG Recommendations 
7.1 Regarding the Common IGP for the IP Internet 


Based on the available operational experience and the pressing need 
for a high functionality IGP for the IP protocol family, the IESG 
recommends that OSPF be designated as the common IGP for the IP 
portions of the Internet. To help ensure that this IGP is available 
to all users, the IESG recommends that the IETF Router Requirements 
Working Group specify OSPF as "MUST IMPLEMENT" in the document 
"Requirements for Internet IP Routers". 
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7.2 Regarding Integrated Routing 


As mentioned above, the IESG is commited to multiprotocol 
environments, and expects usage of OSI CLNP to increase in the 
Internet over time. 


However, at this time, the IESG is not prepared to take a position 
regarding the preference of either "Ships in the Night" or Integrated 
routing for such mixed routing environments. At this time, the 
"Ships in the Night" approach is most widely used in the Internet. 
Integrated routing has the potential advantage of reducing resource 
utilization. However, additional operational experience is needed 
before any potential advantages can be fully evaluated. 


Therefore, the IESG wishes to encourage implementation of Integrated 
IS-IS so that a reasonable position can be determined based on 
operational experience. All implementers of Integrated IS-IS are 
encouraged to coordinate their activity with the IETF IS-IS Working 
Group, which is actively collecting information on such experience. 


7.3 Limits of the Recommendation 


It is useful to recognize the limits of this recommendation. This 
recommendation does not take a position on any of the following 
issues: 


1. What IGP (if any) users should run inside an AS. Users are free to 
run any IGP they wish inside an AS. 


2. What IGP is technically superior, or has greater operational 
utility. 


3. What IGP any vendor should recommend to its users for any specific 
environment. 


4. What IGP should be used within a CLNP-only environment. 


Again, this recommendation is meant to designate one modern high 
functionality IGP that should be implemented by all vendors of 
routers for the IP portion of the Internet. This will enable routers 
from vendors who follow this recommendation to interoperate within a 
single IP Autonomous System. 


It is not our intent to discourage the use of other routing protocols 
in situations where there may be sound technical reasons to do so. 
Therefore, developers of Internet routers are free to implement, and 
network operators are free to use, other Internet standard routing 
protocols, or proprietary non-Internet-standard routing protocols, as 
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they wish. 
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9. 


10. 


Security Considerations 


Security issues are not discussed in this memo. 
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